1. Field of the Invention
The present invention is directed to a system for defining, using and customizing items in a dialog box.
2. Description of the Related Art
Many computers utilize a windows environment. A window is a user interface element that delimits an area on the screen in which a user can enter and view information. Software applications that have a user interface, can use windows to communicate with the user. A software application (or simply “application”) is computer software that performs a particular task. Any piece of information that an application needs to present to a user can be displayed in a window. Similarly, any piece of information that an application needs to solicit from a user can be obtained by requesting the user to perform appropriate actions in a window. Appropriate actions means that the user types in information, edits information, checks a box or uses a mouse to click on a button or icon.
There can be at least two general kinds of windows: document windows and dialog boxes. Document windows are used primarily to allow the user to enter and manipulate information, such as text, graphics or other data. Often, but not always, the information in a document window can be stored in a file, from which the user can later retrieve the information.
The dialog box is a window that is used for some special, limited purpose. In the simplest case, a dialog box can be used to display information to the user. The information might be a report of an error, a greeting, or a progress bar showing what percentage of some operation has been completed. A dialog box is usually a pop-out window that an application uses to display or prompt for information. In some cases, the information is needed to complete a command. Dialog boxes can display information to the user, allow the user to change information and allow the user to enter additional information. A dialog box can contain one or more items, with which the user can type text, choose options, or direct the action of a particular command. The items include, but are not limited to, a button, a check box, editable text, a help item, icon, a picture, radio button, and static text. The above listed items are predefined items. An applications developer also can create user-defined or customized items.
FIG. 1 shows dialog box 10, which may be used as part of an application to draw Venn Diagrams. Dialog box 10 includes various items. For example, dialog box 10 includes a button 12 (“Save current preferences”). If the user clicks on button 12, the application will save all the selections the user made in the dialog box. The term “click” is defined to include the act of the user, using a mouse, placing the cursor over the button and depressing a button on the mouse. The mouse can be replaced by another apparatus for positioning the cursor. Dialog box 10 also includes four check boxes 14, 16, 18, 20, all of which have associated static text. For example, check box 14 has static text “Give existential import to subjects.” In an alternative embodiment, each of the static text can be thought of as separate items. While the dialog box is active on a screen, the user can click on the check box. Clicking on the associated check box (14, 16, 18 and 20), toggles the check box between chosen and unchosen states. When the user clicks on button 12, the features that are chosen from check boxes 14, 16, 18 and 20 are stored and used by the application in producing the Venn Diagram.
Dialog box 10 also includes eight radio buttons 30, 32, 34, 36, 38, 40, 42 and 44. Each radio button has an associated picture 46, 48, 50, 52, 54, 56, 58, and 60, respectively. Each of these pictures shows an available feature; for example, picture 46, 48, 50 and 52, show the existence of symbols, and pictures 54, 56, 58 and 60 show emptiness patterns that can be used in the Venn Diagram. The user can click on various radio buttons to select or deselect any of the symbols or emptiness patterns. When the user clicks Save Button 12, the selected patterns and symbols are stored. Alternatively, pictures 46, 48, 50, 52, 54, 56, 58 and 60 can be separate icons.
Dialog boxes tend to be easier to create and manage as compared to document windows. Many computers will have a Dialog Manager that manages or oversees the use of dialog boxes. The Dialog Manager reads a description of the dialog box and the items inside the dialog box. The Dialog Manager then draws the dialog box and process (or manage the response to) user actions that effect the dialog box. The Dialog Manager's duties include manipulating items in a dialog box, including but not limited to, drawing an item, erasing an item, changing the appearance of an item and overseeing the handling of any event which effects the item.
Currently, the behavior of a dialog box and its items are defined in the Dialog Manager, the windows system, or in an application. The phrase “defining behavior” includes, but is not limited to, defining how and where to draw dialog boxes and dialog items, various attributes of the items (e.g. font, point size, color, test, etc.) and what actions need to be performed when an event occurs (for example when a user clicks on an item, enters text in an item, edits text in an item or performs any other action involving an item or dialog box). When designing a Dialog Manager and accompanying software, the Dialog Manager includes predefined items for an applications programmer to use in dialog boxes. Thus, a windows environment may come with a library of predefined items.
The current use and structure of dialog boxes and dialog items has given rise to some hardship in regard to software development. A first hardship occurs when the provider of the Dialog Manager or windows system, and perhaps the operating system, desires to make changes to the library of predefined items. Changes to the library include adding more items or changing the definition of preexisting items. Making changes to the library usually requires making changes to the Dialog Manager, and possibly the windows system or the operating system (the Dialog Manager may or may not be part of the operating system). Additionally, after completing the changes to the library, the operating system and the Dialog Manager may need to be recompiled in order to take advantage of new features. In most cases, if the operating system, window system or Dialog Manager are recompiled, applications that run on the operating system or windows system must be recompiled in order to take advantage of the new features. Thus, as the provider of a window system or Dialog Manager adds new items or changes items in the library, every application running on the system may need to be recompiled. This is burdensome on the users and applications developers.
Furthermore, changes in the library may make other library items or software applications obsolete. Specifically, if the definition of an item is changed other items which incorporate that item or applications which incorporate that item will no longer function properly and may need to be edited.
A third hardship arises when an application developer (developer) needs to use an item that does not appear in the predefined item library. Thus, the applications programmer creates a new, customized item. Currently, creating a customized item requires a lot of effort. The applications programmer must understand how the Dialog Manager works and how to override various features of the Dialog Manager to deal with a new type of item. Also contributing to the hardship is the possibility that the applications developer does not have the ability to easily incorporate all the prior definitions and code used to define the original library.
Another problem is that each item's behavioral definition may include instructions for behaving in various situations. When the Dialog Manager accesses an item's behavioral definition, there is only one point of entry for the Dialog Manager. Currently, behavioral definitions are typically defined by a list of instructions. When the Dialog Manager accesses the item, the Dialog Manager reads the first instruction on the list of instructions followed by reading the second instruction and so on, until the Dialog Manager completes all the necessary steps as defined in the list of instructions. However, the Dialog Manager may only need to execute a small subset of instructions to carry out the desired task. Thus, it is a waste of processing time for the Dialog Manager to execute instructions not pertinent to the desired task. Additionally, having only one entry point requires a developer to create code to handle the flow of control from that one entry point to all sets of behavioral definitions. Thus, the developer may be required to create a large amount of code for simple customizations.
When an applications developer creates a customized item, the module defining the new item can be a separate file from or part of the application program. The application may need to be compiled every time the definition of the item is altered. Additionally, when the applications developer is creating a second application, the item defined in the first application would not necessarily be able to be referenced by, for example, a pointer in the second application because part of the code used to create the new dialog item is in the first application. Finally, because the applications developer is overriding various segments of code in the Dialog Manager, a change in the Dialog Manager could render an application (with a custom or user-defined item) obsolete.